Mike  Holbert 


While  Dr.  Carter's  affordability  initiatives  highlight  the  role  of  program  managers  in 
creating  program  affordability,  a  closer  review  shows  a  majority  of  program  ef¬ 
ficiencies  can  result  from  implementing  program  rigor  through  effective  systems 
engineering,  or  if  you  prefer,  systems  thinking.  How  so? 

It's  the  system  engineering  process  that: 

•  Breaks  down  the  requirements  into  understandable/actionable  units  for  analysis,  establishing  system,  sub¬ 
system,  and  component  qualities  and  capabilities. 

•  Provides  the  analysis  leading  to  design  solutions  via  detailed  designs  and/or  processes  and  procedures. 

•  Provides  the  analysis  to  make  supportability  decisions  years  before  the  end  item  is  even  tested. 

•  Identifies  the  technical  roles  and  the  potential  solutions  which  become  the  basis  for  the  Acquisition  Strategy. 

•  Ensures  alignment  of  requirements,  specifications,  and  statement  of  work. 

•  Generates  the  decision-quality  information  to  drive  the  effort  to  completion. 

•  Ensures  an  integrated  and  interoperable  system  from  beginning  to  end. 


Holbert  is  a  professor  of  program  management  at  DAU.  He  has  22  years  of  acquisition  management  experience  in  engineering,  program 
management  and  logistics  management  of  Air  Force  and  Joint  programs. 
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While  I  could  go  on  about  the  ad 
vantages  of  a  disciplined  systems 
engineering  approach,  the  real 
challenge  is  not  in  simply 
identifying  how  it  ought 
to  work,  but  in  delivering 
affordable  performance 
through  consistent, 
persistent  intellectual 
focus  and  action. 


Affordability  is  and,  frankly,  has 
always  been  an  ever-present  concern, 
but  it  has  for  the  most  part  been 
"talked  around"  in  the 
acquisition  strategy. 


used;  models  do  not  and  cannot  as¬ 
sure  disciplined  processes  are  ex¬ 
ecuted,  or  disciplined  decision 
making  is  followed.  Sorry  to 
say,  yes,  this  dilemma  does 
apply  to  the  beloved  en¬ 
gineering  "CSEP,"  "Vee," 
the  older  "Engine,"  and 
even  the  "Affordable 
System  Operational 
Effectiveness"  models. 


Common  to  many  of 
the  23  affordability  ini¬ 
tiatives  is  the  implied 
use  of  disciplined  pro¬ 
cesses  to  enable  disci 
plined  decision  making  at 
all  levels,  using  appropriate 
data.  To  aid  this  leadership/ 
management  function,  there 
are  eight  systems  engineering 
technical  management  processes  to 
help  provide  intellectual  focus  and  track¬ 
ing  of  actions: 

•  Decision  analysis:  the  deliberate  process  for  making 
optimum  decisions 

•  Technical  planning:  defining  the  scope  of  the  technical  ef¬ 
fort  required  to  develop,  field,  and  sustain  the  system 

•  Technical  assessment:  the  process  of  reviewing,  ana¬ 
lyzing,  and  evaluating  a  series  of  technical  products  to 
determine  effectiveness  in  meeting  the  systems  capability 
requirements 

•  Requirements  management:  assuring  traceability  of 
allocated  and  derived  requirements  to  the  user  defined 
capabilities 

•  Risk  management:  identification,  analysis,  mitigation,  and 
tracking  of  root  causes  that  impose  a  probability  you  will 
not  meet  cost,  schedule,  or  performance  requirements 

•  Configuration  management:  identifies,  documents,  audits, 
and  controls  the  functional  and  physical  characteristics  of 
the  system  design 

•  Data  management:  the  process  to  acquire,  access, 
manage,  protect,  and  use  data  to  support  the  product 
throughout  its  life 

•  Interface  management:  control  measures  and  processes 
to  document  and  communicate  physical  and  functional 
attributes  of  a  product  or  system 

Each  of  these  systems  engineering  technical  management 
processes  is  further  described  in  chapter  4  of  the  Defense 
Acquisition  Guidebook.  When  properly  executed,  these  tech¬ 
nical  management  processes  allow  clear  insight  into,  and 
control  of,  the  technical  processes  used  to  develop  and  field 
a  capability.  The  technical  processes  are  espoused  in  the 
various  versions  of  the  systems  engineering  "Vee"  model 
and  the  newer  "Comprehensive  Systems  Engineering  Process 
(CSEP)"  model.  However,  a  dilemma  exists  with  any  model 


This  is  where  the  joint 
leadership  by  the  pro¬ 
gram  manager  and  sys¬ 
tems  engineer  (a  PM's 
technical  conscience) 
must  ally  with  each  other 
r  to  pre-think  and  pre-plan 
driving  process  and  decision 
discipline,  and  thus  affordability. 
These  eight  technical  management 
processes  provide  the  context  for  the  rest 
of  this  discussion.  They  apply  to  the  program 
manager  and  other  key  stakeholders,  both  up  and  down 
the  decision  chain. 

Start  Well  by  Knowing  Your  Destination 

The  purpose  of  any  systems  engineering  model  is  to  help  the 
program  manager  and  the  program  team  understand  activities 
and  logical  decision  points  as  the  effort  progresses.  Due  to 
the  structured  nature  of  the  systems  engineering  process  and 
the  checks  and  balances  of  the  eight  technical  management 
processes,  a  program  manager  can  make  informed  decisions 
at  the  beginning  of  a  program  and  throughout  its  life  cycle  to 
determine  which  requirements  lead  to  the  greatest  affordabil¬ 
ity  dividends.  To  understand  how  this  works,  let's  look  at  the 
"Hierarchical  Systems  Engineering  Vee"  model  (Figure  1).  In 
the  Requirement  Definition  process,  senior  decision  makers 
must  focus  on  these  critical  questions: 

•  What  is  the  capability  or  function  of  the  program  or 
product? 

•  How  much  are  we  willing  to  pay  for  each  product,  "a 
worth"  determination? 

•  Is  the  solution  "affordable?" 

•  Does  the  schedule  meet  the  need  as  well  as  the  "invest¬ 
ment  plan"? 

•  What  is  the  expected  level  of  "process  conformance"  by 
the  program? 

This  requirements  definition  activity  starts  the  systems  engi¬ 
neering  effort  in  development  planning  and  arguably  engages 
most  of  the  eight  technical  management  processes.  To  bet¬ 
ter  understand  the  critical  nature  of  the  requirements  pro¬ 
cess,  and  its  impact  on  affordability,  refer  to  Jack  Mohney's 
article  on  the  effective  development  of  joint  operational 
requirements. 
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As  you  move  toward  the  Requirements  Analysis  activity,  plan¬ 
ning  becomes  the  program  manager's  most  critical  task.  Enter 
the  systems  engineer  as  the  program  manager's  specific  ally, 
along  with  some  other  close  allies  like  their  contracting  of¬ 
ficer,  financial  manager,  logistics  manager,  and  their  human 
resources  manager. 

Personal  Involvement  Matters 

As  we  survey  the  rest  of  the  "Vee"  by  moving  through  the 
three  Decomposition  and  Definition  activities,  Implementa¬ 
tion,  and  the  three  Realization  and  Assessment  activities,  it 
causes  us  to  invoke  disciplined  planning.  This  is  underpinned 
with  risk  management,  technical  assessment,  requirements 
management,  interface  management  and  with  a  critical  dose 
of  decision  analysis.  Four  foundational  documents  provide  the 
articulation,  for  all  to  see,  of  how  you  will  exercise  the  eight 
technical  management  processes  to  invoke  consistent,  persis¬ 
tent  intellectual  focus  and  action.  These  documents  are  the 
Acquisition  Strategy  (AS),  System  Engineering  Plan,  Life  Cycle 
Management  Plan,  and  the  Test  and  Evaluation  Master  Plan. 
Each  plan  should  flow  from  the  AS  and  expound  on  how  the 
eight  technical  management  processes  will  be  used  to  deliver 
decision-quality  data  and  ultimately  the  desired  capability. 


•  Justifying  contract  type(s)  and  associated  incentives. 

•  Stating  funding  types  and  timing  for  the  various  types. 

•  Detailing  conformance  to  agreed  to  processes. 

•  Establishing  technology  understanding/maturity  and 
trade  study  expectations. 

•  Stating  how  the  system  is  planned  to  be  sustained  or 
discarded. 

•  Determining  how  to  demonstrate  the  product  works  (as 
the  requirements  have  been  defined). 

•  Including  the  impact  of  either  a  joint  or  international 
partner. 

Perhaps  the  three  most  important  aspects  that  create  the 
overarching  business  strategy  in  your  Acquisition  Strategy 
are  contract  types/incentives,  funding  types/timing,  and 
the  integrated  master  plan  and  the  associated  program 
integrated  master  schedule,  which  may  not  simply  be  the 
contract  schedule.  To  better  understand  the  options  avail¬ 
able  to  the  program  manager  in  his  business  strategy,  I  refer 
you  to  the  article  by  John  Pritchard,  et  al .,  discussing  how 
new  contracting  approaches  impact  program  affordability. 
Affordability  is  and,  frankly,  has  always  been  an  ever-present 
concern,  but  it  has  for  the  most  part  been  "talked  around" 
in  the  AS. 


These  planning  documents  are  much  too  important  to  simply 

outsource  or  "borrow"  from  another  document.  A  program  So  the  recurring  theme  in  planning  discipline  is  to  state 
manager's  personal  involvement  will  have  dramatic  afford-  clearly  how  each  part  of  your  AS  will  work  to  keep  the  total 
ability  impacts— positive  or 
negative.  The  program  man¬ 
ager  must  chart  the  program 
course  through  critically  con¬ 
structing  an  AS  foundation 
and  laying  out  appropriate 
plans  to  execute  the  strat¬ 
egy.  By  doing  so,  the  program 
manager  moves  every  aspect 
of  the  program,  and  every 
person  involved,  in  a  com¬ 
mon  direction  and  a  common 
rhythm. 

The  Play  Book 

The  AS  is  the  program  manag¬ 
er's  and  team's  self-developed 
program  "git-'er-done"  play 
book  and  must  start  by  an¬ 
swering  the  question:  "What 
are  the  program  risks  based 
on  a  clear  understanding  of 
the  defined  requirements  and 
concept  of  operations?"  The 
trick  is  articulating  those  risks 
and  mitigating  them  usingthe 
AS  through: 

•  Describing  the  capability 
being  procured  and  the 
associated  risks. 


Figure  1.  Hierarchical  Systems  Engineering  Vee 
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integrated  program  cost  affordable. 
Be  sure  you  address  each  of  the 
topics  identified  here.  Although 
you  may  be  tempted  to  as¬ 
sume  away  the  impacts 
an  international  partner 
can  have  on  your  strat¬ 
egy,  don't  ignore  this 
potentially  significant 
affordability  driver.  To 
get  better  insight  into 
international  impacts 
on  affordability,  refer 
to  Craig  Mallory's  ar¬ 
ticle  on  international 
programs. 
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How  Do  We  Know 
What  It  Is  and  If  It 
Will  Work? 

The  System  Engineering  Plan  (SEP) 
is  the  joint  program  manager  and  sys¬ 
tems  engineer  document,  but  don't  let 
the  rest  of  your  program  team  side  step  their 
responsibility  to  make  their  inputs/edits,  because  systems 
thinking  is  a  collaborative  team  sport.  This  is  the  program  man¬ 
ager's  document  outlining  how  he/she,  along  with  the  chief 
systems  engineer,  will  invoke  engineering  discipline  in  the  pro¬ 
gram  and  involve  the  entire  team  in  delivering  the  required 
capability.  This  document  encompasses  the  three  Decompo¬ 
sition  and  Definition  activities  and  the  three  Realization  and 
Assessment  activities  and  describes  the  processes  used  to 
connect  them  as  depicted  in  Figure  1.  The  program  manager 
and  the  chief  systems  engineer  should: 

•  Lay  out  the  clear  plan  for  the  technical  architecture,  the 
demarcation  of  the  interfaces,  and  at  what  levels  the  con¬ 
figuration  and  interfaces  will  be  managed. 

•  List  necessary  trade  studies  and  analysis  efforts. 

•  Describe  expectations  regarding  engineering  teams  work¬ 
ing  and  sharing  information. 

•  Describe  how  technical  progress  will  be  assessed,  includ¬ 
ing  long-term  performance  (read  sustainment,  including 
reliability  growth  and  maintainability  improvements). 

•  Identify  how  production  readiness  and  producibility  are 
tracked. 

•  Address  the  approach  to  manage/insert  new  technology 
into  the  program. 

•  Describe  staffing  requirements  necessary  to  execute  this 
effort. 

Why?  Each  one  of  these  areas  affects  the  program's  afford¬ 
ability.  But  the  key  aspect  of  a  SEP  is  the  planned  trade  studies 
and  analysis.  Properly  planning  and  then  driving  these  trade 
studies  into  the  program  will  have  dramatic  effects  on  a  pro¬ 
gram's  affordability  decisions,  through  the  use  of  decision- 
quality  data.  Understandingthe  direction  and  intent  forthese 
studies  invokes  a  self  discipline  and,  therefore,  a  program  de¬ 


Don't  let  the  rest  of  your  program 
team  side  step  their  responsibility 
to  make  their  inputs/edits, 
because  systems  thinking 
is  a  collaborative 
team  sport. 


cision  analysis  discipline  for  the  en¬ 
tire  collaborative  team.  There  are 
two  articles  in  this  very  issue  of 
Defense  AT&.L  that  might  help 
you  in  your  SEP  writing  ef¬ 
forts.  The  first  is  Brian 
Brodfuehrer's  article  on 
program  metrics,  to  help 
you  understand  how  to 
technically  assess  the 
program's  progress, 
and  second  is  a  team 
article  on  effectively 
managingthe  transition 
to  production  by  Dusty 
Schilling  and  Pete  Czech. 
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How  Long  Do  You 
Want  to  Operate? 

The  Life  Cycle  Sustainment 
Plan  (LCSP)  lays  the  foundation 
for  long-term  affordability.  Program 
managers  and  engineers:  Put  your  log- 
gies/sustainers  on  speed  dial— really.  Expect 
engagement  by  your  logistics  manager  on  this  plan;  get  those 
sustainer  ideas  on  all  aspects  of  the  program.  If  sustainers  are 
silent  or  unheard  until  you  walk  through  the  realization  and 
assessment  efforts,  you  can  be  sure  life  cycle  affordability  is 
in  jeopardy. 

Make  sure  those  logistics  managers  bring  their  financial  man¬ 
ager  and  contracting  friends,  because  this  plan  needs  good 
cost  estimating  and  critical  thinking  about  how  it  will  be  imple¬ 
mented  in  the  contract  and/or  with  organic  capability.  I  refer 
you  to  Mark  Husband's  article  on  cost  estimating.  Engineers 
often  believe  a  material  or  software  solution  is  best,  but  a 
human  process  works  just  fine.  I  have  generally  found  loggies 
balance  these  perspectives  and  generate  more  holistic  and 
workable  solutions. 

By  the  way,  did  you  notice  at  the  bottom  of  the  "Vee,"  under 
"Implementation,"  there  are  the  words  "Tech  Data  &  Training 
Pubs"  alongside  "Hardware  Fabrication"  and  "Software  Cre¬ 
ation/Coding?"  Procurement  of  data  rights  for  our  systems 
can  be  a  key  to  both  long-term  system  sustainment  and  afford¬ 
ability.  See  Dave  Gallop's  article  on  the  technical  data  decision 
process.  Sure  seems  both  engineers  and  loggies  need  to  be 
involved  through  the  Decomposition  and  Definition  effort  as 
well  as  through  the  Implementation  and  into  the  Realization 
and  Assessment  efforts.  The  LCSP  is  not  just  the  sustainer's 
plan;  it  belongs  to  the  program  manager  and  the  engineers  as 
well.  More  importantly,  it  is  driven  by  how  the  AS  indicates  the 
capability  will  be  sustained  across  the  life  cycle. 

Have  you  ever  noticed  how  loggies  and  engineers  think 
the  same?  Well,  they  generally  don't.  Engineers  like  black 
and  white;  loggies  like  "what  abouts"  and  "what  if s 
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The  LCSP  focuses  engineers  and  loggies  on  a  common 
thought:  "How  will  this  capability  keep  working  long  after 
we  have  all  left  the  program?"  And  more  importantly,  "How 
will  it  stay  sustainable  and  affordable  throughout  its  expected 
life?"  For  a  better  understanding  of  sustainment,  I  refer  you 
to  Bill  Kobren's  article. 

I  Can  Prove  It 

The  Test  and  Evaluation  Master  Plan  (TEMP)  lays  the  foun¬ 
dation  for  a  disciplined  process  of  early  and  timely  confirma¬ 
tion  the  capability  DoD  expects  will  work.  You  have  heard 
the  adage,  "Bad  news  does  not  get  better  with  time."  What 
the  unknown  author  really  meant  was,  "The  later  you  find 
out  things  don't  work,  the  higher  the  ultimate  price  tag."  Said 
another  way,  "The  desired  capability  becomes  increasingly 
unaffordable." 

Nobody  really  likes  to  be  tested,  but  that  is  exactly  what 
moving  up  the  right  side  of  the  systems  engineering  "Vee" 
and  into  the  Realization  and  Assessment  efforts  does.  The 
TEMP  establishes  how  we  will  confirm  to  everyone  involved 
that  what  is  being  purchased  has  the  desired  capability. 
The  TEMP  is  the  proverbial  "Iron  sharpens  iron,  so  one  man 
sharpens  another"  document.  Knowing  the  program  will  be 
tested  makes  engineers  and  loggies  do  their  respective  tasks 
better.  Knowing  tests  are  resource  intensive  (read  expensive) 
makes  program  and  financial  managers  sharpen  their  fund¬ 
ing  allocations.  Understanding  the  answers  to  the  test  ques¬ 
tions  (documented  requirements)  makes  the  requirements 
expectations  clearer. 


You  did  notice  the  horizontal  lines  between  the  three  Decom¬ 
position  and  Definition  activities  and  the  three  Realization  and 
Assessment  activities  to  the  right?  A  good  test  and  evalua¬ 
tion  effort  drives  the  ultimate  in  decision-quality  data.  Have  I 
said  yet  the  TEMP  is  a  team  document?  It  drives  the  cost  by 
virtue  of  its  existence  and  the  weaknesses  it  finds,  but  it  can 
also  help  confirm  a  program’s  capability  and  frame  its  afford¬ 
ability.  For  more  insight  into  improving  affordability  through 
better  testing,  refer  to  Mike  Bohn's  article.  A  great  advantage 
of  systems  engineering  discipline  is  the  early  involvement  by 
the  test  manager  in  a  program. 

Planning  Allows  Graceful  Execution 

All  four  of  these  documents  remind  every  engineer  in  that 
middle  part  of  the  "Vee,"  the  "Decomposition  and  Definition" 
as  well  as  the  "Realization  and  Assessment”  effort,  just  ex¬ 
actly  how  to  make  decisions  with  cost,  and  thus  affordability, 
as  a  foundation.  They  all  chart  the  program  course  and/or 
consistently  remind  everyone  involved  in  executing  the  pro¬ 
gram  that  affordability  is  at  the  forefront  of  each  decision  point 
along  the  path  to  delivering  the  product.  But  just  as  critically, 
they  help  your  senior  stakeholders  determine  if  the  nation's 
wealth  is  being  well  spent.  So  the  next  time  you  see  the  simple 
systems  engineering  "Vee"  model,  know  it  is  the  guide  book 
to  successful  planning  and  execution  of  a  program,  and  your 
secret  weapon  to  successful  delivery  of  an  affordable  capabil¬ 
ity  driven  by  decision-quality  data. 

The  author  can  be  reached  at  michael.holbert  (Sdau.mil. 
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DoD  Acquisition 

Best  Practices  Clearinghouse  (BPCh) 

A  single,  authoritative  source  of  useful,  validated,  actionable  practice  information 

Do  these  issues  sound  familiar? 

•  There  are  many  practice  lists  to  choose  from  but  no  guidance  for  selecting  specific  practices 

•  "Proof  of  practice"  effectiveness  is  usually  not  available 

•  The  connection  between  practices  and  specific  program  risks  are  undefined 

•  Success  factors  for  practices  are  not  well  documented 

•  Implementation  guidance  is  often  missing 

•  The  cost  and  timeliness  associated  with  implementing  and  using  the  practices  are 
often  not  specified 

The  BPCh  can  help  by: 

•  Serving  as  the  authoritative  source  for  practices  in  DoD  and  industry 

•  Targeting  the  needs  of  the  software  acquisition,  software  development,  systems  engineering, 
program  management,  and  logistics  communities 

•  Connecting  communities  of  practice,  centers  of  excellence,  academic  and  industry 
sources  and  practitioners 

•  Promoting  and  assisting  in  the  selection,  adoption,  and  effective  utilization  of  best 
practices  and  supporting  evidence 

For  more  information,  visit  the  BPCh  web  site  at  https://bpch.dau.mil,  or  contact: 


Mike  Lambert 

michael.lambert@dau.mil 

703-805-4555 


John  Hickok 

john.hickok@dau.mil 

703-805-4640 
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